This PR ports the data loading and UI from the / page of the Ember.js to the Svelte app.

It is use the conventional load() function (see https://svelte.dev/docs/kit/load) to load the data from GET /api/v1/summary, but it is explicitly not awaiting the result in the load() function itself, and instead returns a Promise. This causes SvelteKit to not block the page rendering until the data has arrived. Instead, while the data is being loaded, a skeleton screen with placeholders is displayed, just like in the Ember.js app.

Additionally, on the browser side, the load() function caches the received data, so that it is not re-requested on every page visit. Again, just like in the current Ember.js implementation.

If an error occurs during data loading, then an error state with a retry button is shown to the user. Pressing the retry button will show a loading spinner while trying again to load the summary data. Again, just like in the current Ember.js implementation.

Note that this implementation slightly differs from the Ember.js implementation in that it extracts a couple more components that make it easier to deal with the await blocks in the template. These components however also make it easier to work on and review the component states in the Storybook implementation. 🎉

Visually, the page should look the exact same now as the Ember.js implementation :) ... except for the theme switcher

Alternatives

• A simpler alternative is to use await in the load() function. But, as mentioned above, this would cause SvelteKit to block rendering the page until the data has loaded. The advantage of this would be that server-side rendering would return a regular HTML page that does not need JS to show the data. The disadvantage would be that it takes slightly longer to display the search box, which seems to be the most relevant part of our landing page at the moment. Ultimately it is a tradeoff. I have chosen the the streaming approach for now since it mirrors the Ember.js implementation and makes it compatible with the existing Playwright tests for this page, but that decision is not set in stone and can still be changed in the future.
• Another alternative is using https://github.com/mainmatter/sheepdog to implement the data loading closer to how it is implemented in the Ember.js application. I'm still not entirely sure which way makes the most sense for us here, but I figured I shouldn't get paralyzed by making a choice and so I randomly chose the conventional Svelte way.

Related

• Migrate frontend to Svelte 5 #12515